Indexing and search query processing

ABSTRACT

A method for processing a search query according to one embodiment includes receiving a search query containing terms; combining at least some consecutive terms in the search query to create biwords; looking up at least some of the terms and biwords in a search index for identifying sections of documents containing the at least some of the terms and/or biwords; generating a content score for each of the identified sections based at least in part on a number of the terms and biwords found in the sections of each document, wherein the biwords are given a higher priority than matched terms, wherein the priority affects the content score; and selecting and outputting an indicator of at least one of the sections, or portion thereof, based at least in part on the content score.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims benefit under 35 U.S.C. § 121 as a division ofU.S. patent application Ser. No. 14/927,901, filed Oct. 30, 2015, whichclaims benefit under 35 U.S.C. § 120 as a continuation of U.S. patentapplication Ser. No. 14/161,108, filed Jan. 22, 2014 (now U.S. Pat. No.9,208,185), which claims benefit under 35 U.S.C. § 121 as a division ofU.S. patent application Ser. No. 13/607,535, filed Sep. 7, 2012 (nowU.S. Pat. No. 8,676,820), which claims benefit under 35 U.S.C. § 120 asa continuation of U.S. patent application Ser. No. 11/737,668, filedApr. 19, 2007 (now U.S. Pat. No. 8,290,967), each of which is herebyincorporated herein by reference its entirety.

RELATED DOCUMENTS

The following documents have been filed under the U.S. Patent andTrademark Office Document Disclosure Program. Listed are the number,title, and date of receipt of the document by the U.S. Patent andTrademark Office.

595370: Process and Methods for Product Document Indexing and Search,Feb. 21, 2006 606574: Product Document Indexing and Search, Sep. 21,2006 606576: Splitting Model Number, Sep. 21, 2006 606577: QueryRecommender, Sep. 21, 2006 606579: Post Processing PDF Search Results,Sep. 21, 2006 606573: Product Search User Interface, Sep. 21, 2006 FIELDOF THE INVENTION

The present invention relates to document searching, and moreparticularly, this invention relates to methods for processing searchqueries, and index structures.

BACKGROUND OF THE INVENTION

Many product related documents, such as user's guides, installationguides, and operations manuals, are typically published in non-textformats, for example, the PDF format, and contain a large number ofsections and many pages. Traditional techniques of indexing andsearching a document are designed for small text-based documents such asweb pages which discuss a single subject matter. Accordingly, presentsearching technology is ineffective at finding non-text based documents.

Further, large documents, such as product related documents, may covermany topics which serve different purposes and user needs at differenttimes. The result is that users must first locate a document, and thenopen the document in a specific document reader, e.g. a PDF reader, andthen manually search again within the document to find the right sectionand page for the answers.

Therefore, there is a current need for addressing these and otherproblems associated with document retrieval.

SUMMARY OF THE INVENTION

A method for analyzing and indexing a document includes receiving adocument; converting the document to one or more text streams;analyzing, using a processor, the one or more text streams foridentifying textual contents of the document, wherein the textualcontent contains words and bi-words; analyzing the one or more textstreams for identifying sections of the document; indexing theidentified word or bi-word in association with the sections in whichword or bi-word is located, wherein the indexing further comprisesassigning a predefined priority value to each word or bi-word withineach section; and saving a result of the indexing in a data storagedevice.

A method for processing a search query according to one embodimentincludes receiving a search query containing terms; combining at leastsome consecutive terms in the search query to create biwords; looking upat least some of the terms and biwords in a search index for identifyingsections of documents containing the at least some of the terms and/orbiwords; generating a content score for each of the identified sectionsbased at least in part on a number of the terms and biwords found in thesections of each document, wherein the biwords are given a higherpriority than matched terms, wherein the priority affects the contentscore; and selecting and outputting an indicator of at least one of thesections, or portion thereof, based at least in part on the contentscore.

An index structure for keyword searches, the index structure beingembodied on a computer readable storage medium, includes a plurality ofcontent words and biwords, the biwords comprising consecutive singleword terms; for each of the content words and biwords, at least onedocument identifier containing information about a document containingthe content word or biword; for each of the document identifiers, atleast one position identifier containing information about a section inthe document containing the content word or biword; and for each of theposition identifiers, at least one priority bit containing a priority ofthe word or biword associated with the position identifier, wherein ahigher weight is assigned to word or biword matching at the positionidentifier with the priority bits set than at another positionidentifier without the priority bits set.

Other aspects and advantages of the present invention will becomeapparent from the following detailed description, which, when taken inconjunction with the drawings, illustrate by way of example theprinciples of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

For a fuller understanding of the nature and advantages of the presentinvention, as well as the preferred mode of use, reference should bemade to the following detailed description read in conjunction with theaccompanying drawings.

FIG. 1 illustrates a flow diagram of a method for analyzing and indexingan unstructured or semistructured document in accordance with oneembodiment of the present invention.

FIG. 2 illustrates a preferred embodiment for processing, indexing, andsearching an unstructured or semistructured document in accordance withone embodiment of the present invention.

FIG. 3 illustrates a preferred embodiment of the data model used forprocessing product documents in accordance with one embodiment of thepresent invention.

FIG. 4 illustrates a data model utilized in the conversion of a PDF toan XML, document in accordance with one embodiment of the presentinvention.

FIG. 5 illustrates an internal record organization in accordance withone embodiment of the present invention.

FIG. 6 demonstrates the relationship between a PDF char stream and alogical char stream in accordance with one embodiment of the presentinvention.

FIG. 7 illustrates a flow diagram of a method for analyzing and indexingan unstructured or semistructured document in accordance with anotherembodiment of the present invention.

FIG. 8 illustrates a flow diagram of a method for processing a searchquery in accordance with one embodiment of the present invention.

FIG. 9 illustrates one embodiment of the present invention.

FIG. 10 illustrates an example of a traditional lookup, merge, and sortwhich may be implemented in an embodiment of the current invention.

FIG. 11 illustrates an example of a preferred embodiment for contentlookup, merge, and sort in accordance with one embodiment of the presentinvention.

FIG. 12 illustrates a flow diagram of a method for processing a searchquery in accordance with one embodiment of the present invention.

FIG. 13 illustrates a landing page in accordance with one embodiment ofthe present invention.

FIG. 14 illustrates a landing page implementation in accordance with oneembodiment of the present invention.

FIG. 15 illustrates a search result page in accordance with oneembodiment of the present invention.

FIG. 16 illustrates an implementation of the search results pagedisplaying a PDF document page in accordance with one embodiment of thepresent invention.

FIG. 17 illustrates an example of the search results page displayingcontent from a web site in accordance with one embodiment of the presentinvention.

FIG. 18 illustrates an example of the process of submitting a query anddisplay results between the client browser and the server in accordancewith one embodiment of the present invention.

FIG. 19 is a flow diagram of a method for indexing a product identifierand logical parts thereof in accordance with one embodiment of thepresent invention.

FIG. 20 is a flow diagram of a process for indexing a product identifierand variations thereof in accordance with one embodiment of the presentinvention.

FIG. 21 illustrates a network architecture in accordance with oneembodiment of the present invention.

FIG. 22 shows a representative hardware environment, in accordance withone embodiment of the present invention.

FIG. 23 shows Table 8, which illustrates text reading order and internalPDF char offset, in accordance with one embodiment of the presentdisclosure.

FIG. 24 shows Table 12, which illustrates a Lucene inverted word index,in accordance with one embodiment of the present disclosure.

FIG. 25 shows Table 13, which illustrates a position id, in accordancewith one embodiment of the present disclosure.

FIG. 26 shows Table 14, which illustrates a paragraph file layout, inaccordance with one embodiment of the present disclosure.

BEST MODE FOR CARRYING OUT THE INVENTION

The following description is the best mode presently contemplated forcarrying out the present invention. This description is made for thepurpose of illustrating the general principles of the present inventionand is not meant to limit the inventive concepts claimed herein.Further, particular features described herein can be used in combinationwith other described features in each of the various possiblecombinations and permutations.

Unless otherwise specifically defined herein, all terms are to be giventheir broadest possible interpretation including meanings implied fromthe specification as well as meanings understood by those skilled in theart and as defined in dictionaries, treatises, etc.

To aid the reader, much of the following description will be presentedin terms of a Portable Document Format (PDF) document. It should beunderstood that this is done by way of example only, as the teachingsherein are applicable to all types of unstructured and semistructureddocuments.

FIG. 1 illustrates a flow diagram of a method 100 for analyzing andindexing an unstructured or semistructured document in accordance withone embodiment of the present invention.

As shown in FIG. 1, a document is received in step 102. The document maybe unstructured or semistructured. For example, the unstructured orsemistructured document may be in a printer format, such as PortableDocument Format (PDF), or PostScript (PS) format, etc. The unstructuredor semistructured document may also be a binary representation of darkand light areas of a scanned document. Further, the unstructured orsemistructured document may not contain format markers. No informationmay be known about these documents, e.g. how lines of text fit togetherinto paragraphs and sections, etc. Examples of unstructured orsemistructured documents may include user manuals for electronicdevices, product specification sheets, etc.

In step 104 the document is converted to one or more text streams.Additionally, in step 106 the one or more text streams are analyzed foridentifying textual contents of the document. The textual contents mayinclude words in the document. Also, in step 108 the one or more textstreams are analyzed for identifying logical sections of the document.The sections may include groups of paragraphs of the document, eachparagraph being individually detected by analyzing the one or more textstreams. An extraction process may be performed in order to assist inthis identification. Additionally, in step 110 the textual contents areassociated with the logical sections. Further, in step 112 the textualcontents and their association with the logical sections are indexed.Further still, the indexing may include assigning a weight to thetextual contents. Also, in step 114 a result of the indexing is saved ina data storage device, for example a nonvolatile memory device, e.g.,hard disk drive; volatile memory; etc.

In one embodiment, the content of the document is stored inside anindex. Each word from the content may be further tagged with the sectionand paragraph from which the word comes from. In another embodiment, oneor more text streams may be analyzed for identifying context informationabout each section, and the context information and the association ofthe textual contents and context information may be indexed with thelogical sections.

One preferred embodiment for processing, indexing, and searching anunstructured or semistructured document is shown in FIG. 2. As shown, aPDF document 202 in this example is converted to an Extensible MarkupLanguage (XML) format document 206 in step 204. The conversion processextracts the text elements and the bookmark information from the PDFfile. Bookmark information is used later to create or assist in thecreation of Table of Contents (TOC) entries.

Data Model

A preferred embodiment of the data model used for processing productdocuments is shown in FIG. 3. As shown, the vendor module 302 comprisesa vendor id and name of the products produced by the vendor. No twovendors will typically have the same vendor id. Additionally, theproduct module 304 comprises a product id, a model number, a UniversalProduct Code (UPC), and a description. No two products may have the sameproduct id. The product module 304 may also contain informationregarding one or more vendors that produced the product (may be morethan one due to possible merger or acquisition) as well as informationon the documents that are written for this product.

Further, the document module 306 comprises a document id, URL and othermeta data about the document, and the products that this document iswritten for (a document can be written for multiple products, typicallywhen the multiple products are variations of a single product model). Notwo documents may have the same document id. The document module 306 mayalso contain Table of Contents (TOC) entries, index entries, sections,and pages. Also, the index entry module 308 contains documentinformation and an index id, where no two index entries may have thesame index id and document information. The index entry module 308 alsocontains the text of the index entry, among other information.

The TOC entry module 310 contains document information and an entry id,where no two TOC entries may have the same entry id and documentinformation. The entry module 310 further comprises the title of the TOCentry, subsections under this TOC entry, and a parent TOC entry thatcontains the current TOC entry. Further, the section module 312 containsdocument information and a section id, where no two section entries mayhave the same section id and document information. The section module312 also contains a TOC entry for the section as well as paragraphsbelonging to the section.

The paragraph module 314 contains section information and a paragraphid, where no two index entries may have the same paragraph id andsection information. The paragraph module 314 further comprises the textof the paragraph and the starting page for the paragraph. Additionally,the page module 316 contains document information and a page id, whereno two page entries may have the same page id and document information.The page module 316 also contains a local page number and the paragraphsthat start on the page.

An illustration of the data model utilized in the conversion of a PDF toan XML, document is shown in FIG. 4. As shown, the data model containsdata regarding one or more of pagelabel 402, fontspec 404, page 406, andlink 408. The data model further contains data regarding one or more ofblock 410, line 412, and text 414.

Table 1 defines the aforementioned data model and illustrates oneexample of the output of the conversion to an XML file. Software toolssuch as xpdf (available from http://www.foolabs.com/xpdf) use a similaroutput format for the XML file.

TABLE 1 <PDFxml> This is the outer most tag, everything else is enclosedin here. <bookmark> Start of the bookmark section. <link> One or morelinks. Each link describe a single entry in <link>...</link> thebookmark, attributes are: title, level, page, etc. A </link> link maycontain other link tags for subsections. ... </bookmark> End of thebookmark section. <pagelabels> Start of the page label section.<pagelabel ... /> One or more page labels. Each tag describes a single... range of pages using a particular page label style. Attributes are:pageidx, type, prefix, and start </pagelabels> End of the page labelsection. <page ...> Start of a page. Attributes are number, top, bottom,width, and height. <fontspec ... /> Zero or more fontspec tags. Eachfontspec describes a ... font that is first used on this page.Attributes are id, family, and size. <block ...> Start of a block tag.Attributes are xmin, ymin, xmax, ymax, numlines <line ...> Start of aline tag. Attributes are xmin, ymin, xmax, ymax, base, charpos, andcharlen <text ...>...</text> One or more text tags. Each text tagcontains the font ... attribute, which points to a font id in apreviously seen fontspec tag. Body of the tag contains the text. Thebody may also contain <b> . . . </b> or <i> . . . </i> style modifierfor bold, italic, or bold and italic text. </line> End of the line tag,other line tags may follow. ... </block> End of the block tag. Otherblock tags may follow. ... </page> End of the page tag. Other page tagsmay follow. ... </PDFxml> End of the outer tag

Continuing with the PDF example, a PDF format document only containslayout information, for example text geometry and font size. Thedocument does not contain logical information such as section,paragraph, and sentences. For each text segment extracted, the segment'sgeometry and font information is saved. A text segment is a singlesequence of characters of a particular font family, size and style.Then, the text segments that are close together are combined to formlines. Each line is made of multiple text segments along the line'swriting axis. Finally, multiple lines that are closer together areplaced inside a text block.

Page Number Extraction

Referring again to FIG. 2, in step 208 the page numbers may be extractedfrom the document, resulting in meta data 216. Document pages have aphysical page index as well as a logical page number. Page numbers canbe numeric such as 1, 2, 3, etc. or have prefixes such as 1-1, 1-2, 2-1,2-2, or non-numeric such as i, ii, iii, a, b, aa, bb, etc. Files such asPDF files can embed page number information. When embedded, the PDF toXML conversion may issue pagelabel attributes.

When the document does not contain any embedded page labelinginformation, pattern extraction may be used to determine the pagenumbering. To do this, the lines on each page are sorted by the primaryrotation. The primary rotation indicates whether the text on the page ismostly facing up, facing right, facing down, or facing left. From thispoint on, the word “top” and “bottom” are used with respect to theprimary rotation. For example, if the primary rotation is facing right,then “top” means “right-most” and “bottom” means “left-most”.

Additionally, any repeating lines across pages are detected and deleted.Repeating lines occur when the author places text such as chapter titleand copyright notices on multiple pages. To detect repeated lines, aline from page N is chosen and it is determined if another line with thesame text appears at the same location in page N+1, N−1, N+2, or N−2.The reason for using N+2 and N−2 is that sometimes text may repeat onthe odd or the even pages only.

After the repeating lines are eliminated, all the lines appearing at the“bottom-most” edge of the page are selected. Then each line is placedinside one of multiple locations along the bottom edge. The example,illustrated in Table 2, uses 6 locations, though more or less may beimplemented.

TABLE 2 Getting 2 Started 1/6 2/6 3/6 4/6 5/6 6/6

In the above table, the text “2” appears at the 1/6 location. The text“Getting Started” appears at the 6/6 location. For page N and eachlocation of N, a delta is computed using the text extracted at thatlocation and subtract the text found on the largest page prior to N thatalso has a piece of text at the same location. For the purpose of thisdelta computation, only numeric page numbers are used in one embodiment.Numeric page numbers may be any text in one of the following formats, asshown in Table 3.

TABLE 3  <prefix> - <number> E.g. 1-1, A-1  <text> <number> E.g. 1, 20,2 Getting Started, Getting Started 2  For example, if page's 1/6location contains the text {<empty> 2 <empty> 4 <empty> 6 <empty> ...},then the corresponding offsets for the 1/6 location is {<empty> <empty><empty> 2 <empty> 2 <empty> ...}

Using the offsets from the various locations across all pages, the pagenumbers for the documents can be determined using the following tests:

-   -   2 page inner: there are two logical pages per physical page. The        page number occurs at the 3/6 and 4/6 location respectively for        each of the logical pages. This scenario is detected by seeing        if the offset is 2 for the 3/6 or the 4/6 location for most of        the pages in the document.    -   2 page outer: there are two logical pages per physical page. The        page number occurs at the 1/6 and 6/6 location respectively for        each of the logical pages. This scenario is detected by seeing        if the offset is 2 for the 1/6 or the 6/6 location for most of        the pages in the document.    -   2 page middle: there are two logical pages per physical page.        The page number occurs at the 2/6 and 5/6 location respectively        for each of the logical pages. This scenario is detected by        seeing if the offset is 2 for the 2/6 or the 5/6 location for        most of the pages in the document.    -   1 page middle: there is one logical page per physical page. The        page number occurs at 3/6 or 4/6 location. This scenario is        detected by seeing if the offsets are 1 for the 3/6 or the 4/6        location for most of the pages in the document.    -   1 page outer: there is one logical page per physical page. The        page number occurs at the 5/6 or the 6/6 location. This scenario        is detected by seeing if the offsets are 1 for the 5/6 or the        6/6 location for most of the pages in the document.    -   1 page outer mirror: there is one logical page per physical        page. The page number occurs at the 1/6 or the 2/6 location, and        alternates to the 5/6 and the 6/6 location on the next page.        This scenario is detected by seeing if the offsets are 1 for the        1/6, 2/6, 5/6 or the 6/6 location for most of the pages in the        document.

When the style of the page layout is determined to be one of the 6scenarios, the page number is extracted from the corresponding textlocated at the right location from each page to produce a list oflogical page numbers. If the offset test fails for all 6 scenarios, thenthe “top-most” line is used to see if the page numbering occurs at thetop of the page. For detection at the top of the page, a similar set ofsteps is followed: duplicate elimination, place text into multipleseparate locations, compute offsets, and look for offset patterns.

If page numbers cannot be detected from either the top or the bottom ofthe page, an error is flagged for human intervention to see if thedocument is an exception to the above rules. Alternative schemes ofdetecting page numbers may also be used.

Paragraph Extraction

Referring again to FIG. 2, in step 210 paragraphs may be extracted fromthe document. PDF documents do not contain information about logicalparagraphs. During PDF to XML, conversion, the geometry informationabout lines may be output. Lines are then placed inside blocks based onthe line proximity to each other with respect to their font size. Theseblocks may be analyzed for joining lines into paragraphs. To reconstructthe logical paragraph, the primary rotation of a page is determined. Theprimary rotation is the direction on which most of the text is written.From this point on, all directions are with respect to the primaryrotation. For example, if most of the text is facing right, then theprimary rotation is up. The direction “up” points to the physical right;“left” points to physical up, “right” points to physical down, and“down” points to the physical left. Additionally, each page is splitinto multiple logical pages, and each logical page is divided intocolumns. For each column, the blocks are ordered yx, meaning order byascending primary rotation dimension, followed by left-to-right for theperpendicular dimension. Further, iterations are performed through allblocks, for block N:

-   -   If N has one line inside, and block N+1 has one line, and both        lines are using the same base line, lines are added from both        blocks into the current paragraph.    -   Else make consecutive lines in the block with the same font        family, size, and style into the same paragraphs. The line style        is bold or italic if all text within are bold or italic. The        font size of a line is the font size of the first text segment        inside the line.

TOC Extraction

Referring to FIG. 2, again in step 208 the Table of Contents (TOC) maybe extracted from the document, resulting in meta data 216. The TOC isextracted in various ways: by reading the bookmarks from a PDF file, byanalyzing the text in the PDF file, or both. Some PDF documents haveembedded bookmark information. Each bookmark is a link with a title anda physical page index pointing to a physical coordinate on a page. Thisinformation, when present, is outputted to the XML file during the PDFto XML conversion.

For PDF documents that don't have embedded bookmarks, pattern extractionis used to form the TOC. TOC extraction is performed after a page isdivided into logical pages and each of the logical pages is divided intocolumns. TOC extraction then operates on each of the columns. To createthe TOC, starting on the first page a search is performed for a blockwith the text “Contents” or “Table of Contents” within the columns ofthe page. Once found, it represents the start of the TOC. Then a searchcontinues from that point to look for lines with the text “Index”, orhave a font size greater than or equal to the TOC heading size. Thelines between the starting and the ending points are then processed forTOC entries.

To process a TOC entry, each line is analyzed to determine if it endswith a number. If it does, then the text before the number representsthe entry title with the number representing the logical page number. Ifa line does not end with a number, then the next line is analyzed to seeif it has the same font and size. If it does, then the entry is made oftwo lines with the second line being a continuation of the first line.The text is joined between the two lines and checking continues to seeif there is a page number for this entry. Otherwise, the line is notused as a TOC entry because it has no page number associated with it.

For each TOC entry found, its font family and size is pushed onto astack. TOC entries of the same font family and size are considered to beat the same level. Each TOC entry can be a member of another TOC entry.This is accomplished by adding the current TOC entry to the last TOCentry that has a different font family and size in the next location onthe stack. When no parent entry is found, then this TOC entry is at theroot level. At the end of this process, the TOC entries form ahierarchical tree.

Note that a TOC tree produced through text pattern analysis containslogical page numbers while a TOC tree produced through embeddedbookmarks contains physical page index. Hence, a TOC tree producedthrough text pattern analysis may require page number detection as wellso that these logical page numbers can be mapped to physical pageindexes.

Section Extraction

Referring again to FIG. 2, in step 212 section extraction is performedon the document, resulting in section data 214. Section extraction isperformed using the extracted TOC of the document to detect sectionboundaries. If the TOC is extracted via text analysis, then the pagenumber for each TOC entry is first mapped to a physical page index usingthe extracted page numbers.

Section extraction starts at the first paragraph after the end of theTOC. The first paragraph after the TOC is used to compare against eachTOC entry to find the first matching entry. This anchors the firstsection after the TOC section to a particular TOC entry in the TOChierarchy.

From that point on, each paragraph on the subsequent pages are scannedagainst the next several, e.g. 2, 3, 4 . . . TOC entries. Assume thesystem uses 3 TOC entries. During this scanning, a particular page maybe jumped to using the page index associated with the TOC entries. Ifany one of the 3 TOC entries is found to match a paragraph exactly, itis then determined if a fuzzy match needs to be performed. A fuzzy matchis required when no exact match is found for the first or the first twoTOC entries. In the case of fuzzy match, the first TOC entry is fuzzycompared against each paragraph between the previous exact TOC match andthe current exact TOC match. If needed, the fuzzy match is continuedusing the 2^(nd) TOC entry against the paragraphs between the firstfuzzy matched paragraph and the current exact TOC matched paragraph.

The fuzzy compare used may be based any string similarity algorithms,e.g. Hamming, Levenshtein, etc.

After a section's boundary is determined, the information about thesection is saved into two files: a section file and a paragraph file.

The section file is a binary file containing one record for eachsection. The section file is named <PDF filename>.section. Records arepacked next to each other without any gaps. Integers stored in therecord are 32 bit in Big Endian byte order. Strings stored in the recordare in UTF-8 format. Inside each record, the following information isstored, as shown in Table 4.

TABLE 4 32 bit int 32 bit int 32 bit int 16 bit UTF-8 String sectionindex section offset parent index UTF length title

As shown in Table 4, the section index starts with 0 and is incrementedby 1 for each section extracted. The section offset represents an offsetinto the paragraph file, in 256 bytes. The parent index represents theparent section index. The UTF length represents the byte length of thetitle field And the title represents the title of the section.

A corresponding file called <PDF filename.section.txt is also generatedthat contains the text version of the file. This file is used fordebugging.

The paragraph file is a binary file containing records for eachparagraph. The paragraph file is named <PDF filename>.para. A record inthe paragraph file may start on the next available 256 boundary.Integers stored in the record are 32 bit in Big Endian byte order.Strings stored in the record are in UTF-8 format. As a result, there maybe gaps between two records. For each paragraph record, the followinginformation is recorded, as shown in Table 5.

TABLE 5 32 bit int 32 bit int 16 bit int UTF-8 String Padding sectionindex page index UTF length paragraph text padding paragraph offset

As shown in Table 5, the section index represents the section thisparagraph belongs to, and the paragraph offset represents the byteoffset in 256 bytes, relative to the starting of the section. This fieldand the section index are stored together inside the first 32 bit int.Additionally, the page index represents the page index on which thisparagraph starts, and the UTF length represents the byte length of theparagraph text. Further, the paragraph text represents the text of theparagraph in UTF-8 format, and the padding represents the bytes used topad the record to the next 256 byte boundary.

The section index and the paragraph offset are encoded into a single 32bit integer. See the section on Index creation on the format of thisinteger.

Table 6 illustrates an example of how the padding is computed.

TABLE 6 Section. Paragraph Page Num Para UTF len Para UTF Absolute Para(4 bytes) (4 bytes) (+2 bytes) string Padding offset in bytes SectionOffset 0:0 1 10 10 bytes (256 − 4 − 4 − 2 − 0 0 10) = 236 bytes 0:1 1300 300 bytes 202 bytes 256 0:3 1 246 246 bytes 0 bytes 512 1:0 2 5 5bytes 241 bytes 768 4 1:1 2 1000 1000 bytes 14 bytes 1792 2:0 2 10 10bytes 236 bytes 2048 9

The section offset is stored as part of the section binary file, as thisstorage format helps to optimize skipping to a specific paragraph of aspecific section. For example, to read Para 2 of Section 1 in the fileabove, one can compute the byte offset by performing the followingcomputation, as shown in Table 7:

TABLE 7 (Section offset * 256) + (Para Num − 1) * 256 bytes = (4*256 +(2 − 1)*256) bytes

Additionally, FIG. 5 depicts the internal record organization and therelationship between the records from the section file 502 and theparagraph file 504, as well as the PDF file 506.

Document Index Extraction

Referring again to FIG. 2, in step 208 the document index may beextracted from the document, resulting in meta data 216. Many documentshave an Index section toward the end. The index contains useful termsfor the document and where in the document the term appears. This indexinformation may be extracted and the word boosted from the index entryon the page the index entry points to. Because the index entry points tological page numbers, the page numbers may be used to map the logicalnumber to the corresponding physical page index.

Taxonomy Extraction

Referring again to FIG. 2, in step 230 taxonomy-related information maybe extracted from the document, resulting in taxonomy information 232.Taxonomy-related information may include identification information suchas product vendor, product identifier (product model number, productname), etc., and may be associated with the textual contents of thedocument. The context of the document may also be correlated totaxonomy-related information. Additionally, the taxonomy information maybe indexed.

Character Offset Index for Keyword Highlighting

Further, a char offset index may be extracted from the document forkeyword highlighting. During the display of PDF pages for a searchresult, it may be desirable to highlight keywords that are entered as apart of the query syntax. It may therefore be desirable to extract thePDF char offset information for the matching keyword in order to performthe keyword highlighting. The PDF char offset is then sent to the PDFrender, which paints a rectangle with background color before paintingthe character producing the highlighting effect.

Inside a PDF file, the text reading order is not necessary the same asthe internal PDF char offset, as demonstrated in Table 8.

Note that chunk 2 is not in sequential order after chunk 1 inside thePDF file. If the search query keyword is “lazy”, then its correspondingPDF char offset 55 may need to be determined in order to instruct thePDF render to highlight the word “lazy” in the above sentence. Also notethat the <space> characters between “jumps over” and “over a” are notpresent in the PDF file. These <space> characters are artificiallyintroduced in the logical paragraph.

To quickly create the highlighting information for a PDF page, a charoffset index is constructed to map between the logical char offset toPDF character offset. The PDF to xml generator may first produce the PDFchar offset for every text chunk from the PDF file. Then during theconstruction of the logical paragraphs, a char offset index may begenerated.

There is one char offset index for each section of the PDF file. Thechar index file is an ordered list of tuples representing key valuepairs, as shown in Table 9.

TABLE 9 Paragraph Logical char PDF page PDF char Chunk Length offsetoffset number offset

The (paragraph offset, logical char offset) is the key. The logical charoffset is the character position relative to the first character of thechunk within the paragraph. The first character of a paragraph has thelogical char offset of 0. See previous sections on how the paragraphoffset is computed.

Using the above example, if the sentence belongs to paragraph offset 3and appears on the page 13 of the PDF document, then the correspondingpart of the char offset index file may contain the following, shown inTable 10.

TABLE 10 . . . (3, 0, 13, 35, 17) (3, 18, 13, 19, 4) (3, 23, 13, 52, 10). . .

The list of key value pairs is ordered in ascending order by the keyvalue (paragraph offset, logical char offset).

During keyword highlighting, the starting character of a word inside thelogical paragraph is first located using the paragraph file for asection. This produces a list of (highlight paragraph offset, first charoffset, word length). Then each value is translated from the list usingthe char offset index file by doing the following for every (highlightparagraph offset, first char offset, word length), preferably but notnecessarily in the following order:

-   -   Locate the largest (paragraph offset, logical char offset) in        the char index file that is smaller than or equal to our given        (highlight paragraph offset, first char offset). This can be        done using a binary search or just a linear scan. A linear scan        can work well because all the (highlight paragraph offset, first        char offset, word length) needing translation can be ordered        first, then the index file can be gone through linearly without        going backward in the char offset file just like during a merge.    -   Compute the PDF offset as (PDF char offset+first char offset        −logical char offset).    -   Compute the PDF length as MIN (PDF chunk length—PDF offset, word        length).    -   If word length is greater than the PDF length computed in step        3, then produce a PDF offset and length for the first set of        characters up to the PDF length in the word. The remaining        characters of the word are recursively check from step 1 as        though it is a new word.

In yet another embodiment, FIG. 6 demonstrates the relationship betweena PDF char stream 602 and a logical char stream 604.

Content Extraction

Referring again to FIG. 2, in step 218 the context of a document may beextracted from the document, resulting in context meta data 220, whichmay be indexed. The context for a document may include the list ofproducts this document is written for. This context can be providedmanually by the person who first obtained this document or extractedfrom the site map where the document was downloaded from. Alternatively,words inside the title page of the document or the URL link of thedocument can be taken and looked up against a well-defined dictionary ofvendor name and product model numbers. For each product identified, thefollowing information is saved as shown in Table 11.

TABLE 11 vendor list of vendor (or vendors if multiple) who created thisproduct, e.g. Sony, Nikon model # model number of this product, e.g.dc4800, e995 UPC (later) UPC serial codes for the product. E.g.01234567900 description a textual description of the product, e.g. “27”flat panel computer display”, “digital camera with zoom”

The UPC and description may be obtained from a separate productinformation catalog after the product is identified by vendor and modelnumber. The context information obtained is then stored in as a set ofmetadata associated with this document.

Search Index Creation

Referring again to FIG. 2, in step 222, after processing a document intosections and extracting its context information, a searchable index 224is created and updated on both the content and the context utilizing anupdate index function 226 and index updater function 228. The indexermay be adapted from Open Source Lucene. The content index is storedinside a Lucene field called “content” while the context information isstored in various other fields.

Content

For each content word indexed, the document, the section and theparagraph from which this word comes from is stored. This is done bymanipulating the word position value inside the Lucene index. Inside aLucene inverted word index, each word is associated with the followinglogical pieces of information, as shown in Table 12.

The doc id points to the documents that contain the given word. Then foreach document, the position id for a document is used traditionally topoint to the offsets within the document on where this word occurs.

During the index creation, each word's position information may bemanipulated such that it is used to encode the section and the paragraphlocation of the given word. The position id is a 32 bit integer. The 32bits are divided into 3 bit sets, as shown in Table 13.

The most significant bit, the sign bit, is not used. The next 13 bitsare used to store the section id within which a word comes from. Usingthis scheme, a document can have up to 2̂13=8192 distinct sections. Thenext 16 bits are used to store the paragraph chunk offset into theparagraph file. Remember that a paragraph file stores each paragraph ona 256 byte chunk alignment. As a result, a value of 23 in the paragraphchunk offset points to the byte offset 23*256=5888 in the paragraphfile. Using this scheme, each section can have a maximum of 65536paragraphs. The size of each paragraph is unlimited. However, theminimum amount of space taken up by a paragraph is 256 bytes inside theparagraph file. The paragraph file layout is shown in Table 14.

The least significant 2 bits are used to store a priority valueassociated for the given word. The value 0 is the default. Other valuesare used to encode the importance of the word. For example, bi-words canbe configured to have a priority value of 1. During scoring, a differentweight is associated to bi-words by checking if a matched word has apriority value of 1.

Context

The document context is one or more products this PDF file is writtenfor, the type of the document, and other meta information. Each productcan be described by one or more identifiers, such as UPC, vendor name,and model number, and a product description. A context index is createdby encoding these context meta data into a special section 0 of thedocument.

Storing meta information into section 0 of the index allows for thesimplification of the index lookup process. The lookup index can be gonethrough using a single loop without the need to merge lookup data acrossseveral indices. The same query keywords may also be used for both thecontent and the context index to easily figure out the aggregate numberof keywords matched.

Since there are several pieces of meta data for the document context,different paragraph locations within section 0 are used to store thedifferent pieces of meta data. Table 15 outlines some of the meta datastored.

TABLE 15 Paragraph # Meta Data Stored 0 Vendor, vendor alias terms 1Product family, family alias terms 2 Full model names 3 Partial modelterms 4 Alpha model terms 5 Document type terms 6 Document title terms 7UPC or vendor part number codes 8, 9 Unused for now 10-32 Special value“_len” used to denote the string length of the full model name >32Unused for now

This method of storing meta data is very flexible. When additional metadata are needed in the future, they can be added to section 0 usingparagraph numbers that are unused.

During the indexing process, some or all of the following specialhandling operations may also be performed:

For the Content Index:

-   -   Remove any words that match the document's vendors and model        number. For example, when indexing a sony e550 document, the        words “sony” and “e550” are not indexed as a part of the        content.    -   Stem each word that is in the plural or past tense form to its        corresponding singular and present form. For example, cats        becomes cat, films becomes film.    -   Detect if a word is a stop word. For example, a, the, it, its,        my . . . are considered stop words. Note that stop words are not        eliminated from the index, they are only detected for the        purpose of performing the next step to create bi-words.    -   Create additional bi-words on any two adjacent non-stop words        from the same paragraph that are separated by a single        non-alphanumeric character such as a space, a dot, a hyphen, or        any other punctuation. A bi-word is created by combining the two        normal words and add a “.” separator in between. When a bi-word        is created, it is assigned to the same section and paragraph id        as the individual words. However, the priority bit for the        bi-word is set to 1 instead of 0. For example, when “how to        operate your digital camera” in a paragraph is seen, the bi-word        created is “digital.camera”. As a result, the index now contains        the following tokens: how, to, operate, your, digital, camera,        digital.camera.    -   Eliminate redundant words within a single paragraph. For        example, if the paragraph contains “ . . . for best quality        pictures, set the picture mode . . . ”, the corresponding index        may contain the following tokens “for best quality picture set        the mode”    -   For the Context Index:    -   Context terms are constructed specially, especially for the full        and the partial model terms.

FIG. 7 is a flow diagram of a method 700 for analyzing and indexing anunstructured or semistructured document in accordance with anotherembodiment of the present invention. As an option, the process 700 maybe implemented in the context of the architecture and environment ofFIGS. 1-6. Of course, however, the process 700 may be carried out in anydesired environment.

As shown in FIG. 7, an unstructured or semi structured document isreceived in step 702. Additionally, in step 704 the document isconverted to one or more text streams. Further, in step 706 the one ormore text streams is analyzed for identifying paragraphs of thedocument, and in step 708 the paragraphs are grouped into sections.Further still, in step 710 the sections, or a derivative thereof, areoutput to at least one of a user, another system, and another process.

Additionally, page numbers may be extracted from the document, and thesections may be associated with the page numbers. Also, the boundariesof the sections may be determined at least in part based on an analysisof a table of contents of the document.

FIG. 8 is a flow diagram of a method 800 for processing a search queryin accordance with one embodiment of the present invention. As anoption, the process 800 may be implemented in the context of thearchitecture and environment of FIGS. 1-7. Of course, however, theprocess 800 may be carried out in any desired environment.

As shown in FIG. 8, a search query containing terms is received in step802. Additionally, in step 804 at least some of the terms are looked upin a search index for identifying sections of documents containing theat least some of the terms. This may include identifying paragraphs inthe sections containing the at least some of the terms and calculating aparagraph score for each of the paragraphs based at least in part on anumber of the terms appearing in each of the paragraphs, wherein asection score is calculated based on the paragraph scores of theparagraphs in the section.

Further, in step 806 a content score is generated for each of thedocuments based at least in part on a number of keywords found in thesections of each document. The content score may reflect all matches inthe document, or the highest section score or scores in one or more ofthe sections. Weighting may be applied to each keyword found in thesections of the documents, where the weighting affects the contentscore. In addition, in step 808 at least some of the terms in the searchindex are looked up for attempting to match one or more of the terms tocontext information in the search index, the context information beingassociated with at least one of the documents. Weighting may be appliedto each keyword matching the context information, where the weightingaffects the context score.

In step 810, a context score is generated based at least in part on thematching of terms to the context information. This may include the casewhere the context score is zero if none of the terms match contextinformation. Further, in step 812 a document score is generated for eachof the documents based at least in part on the content score and thecontext score. The document score may be calculated based at least inpart on the sections scores of the sections of the documents. Also, instep 814 an indicator of at least one of the documents, or portionthereof, is output for the at least one of the documents having a higherdocument score relative to other of the documents. Additionally, anindicator of at least one of the sections having a higher paragraphscore relative to other of the sections may be output. The indicator maybe of a section of the at least one of the documents.

Query Parsing

Referring again to FIG. 2, in step 226 the system can submit user searchqueries to locate the right document and the sections within thedocument. After the GUI accepts the user entered search terms, theapplication server would construct a query based on the given terms.

The user entered keywords go through the following process to arrive ata query:

-   -   lower case all terms    -   remove punctuation and redundant spaces    -   remove stop words    -   convert words in plural and past tense into their non-plural and        present form    -   append additional biwords by joining together consecutive words    -   append a special term “_len”        For example, a user given query:        A brown fox jumps over the lazy dog.        is processed through the following steps:    -   1. lower case all terms: a brown fox jumps over the lazy dog.    -   2. remove punctuation and redundant spaces: a brown fox jumps        over the lazy dog    -   3. remove stop words: brown fox jumps over lazy dog    -   4. remove plural and past tense: brown fox jump over lazy dog    -   5. adding bi-words: brown fox jump over lazy dog brown.fox        fox.jump jump.over over.lazy lazy.dog    -   6. add special term “_len”: brown fox jump over lazy dog        brown.fox fox.jump jump.over over.lazy lazy.dog_len        The constructed query is then submitted to the search engine for        lookup.

Query Recommender

In another embodiment, a query recommender may be utilized. When usermakes mistakes in entering the query, they may not get the expectedresults. The mistake may be a result of misspelled words or imprecisemodel numbers. A query recommender tries to find good alternatives inthese circumstances. For example, the query recommender may be used tocorrect product model numbers.

In one embodiment, the query recommender may correct a single unmatchedterm. When a single query term does not match any document, QueryRecommender shall find alternatives to that term in product modelnumbers. For example, suggest “canon A40” for “canon A45”. In anotherembodiment, the query recommender may find a closer model number. Whenall terms match some document, the query recommender shall take acontent term and find product model alternatives. For example, suggest“sony DCR-DVD200” for “sony dv 200.” Further, the query recommender maysuggest alternatives with too many results. For example, queries like“sony 100” may produce many matches. The query recommender shall suggestalternatives so that user can submit better queries to get more relevantresults. Further still, the query recommender may correct misspelledqueries in recommendations and should return a recommendation in areasonable amount of time because it adds to the duration of the search.In another embodiment, recommended queries may be close to the originalquery. They should constitute an improvement to be displayed. Forexample, it should not be a duplicate of the original query, or theyshould not appear entirely unrelated in any shape or form to theoriginal. Other embodiments may also address integration and priorityissues.

As shown in FIG. 9, in one embodiment, the query recommendation processmay begin with examining the PDF search results for the original query902. The terms for replacement are identified. Based on rest of thematched terms in the query, a dictionary is constructed. Additionally,words from the dictionary are sought that are closest to the replacementterms. If the proximity of the candidates passes certain thresholds, themodel numbers corresponding to these candidates are returned. Further,the query is reconstructed by replacing old terms with suggestions, anddisplaying the end results to the user.

If the above process does not yield a recommendation result in step 920,the query may be sent to a spelling suggestion web service 924, e.g.Yahoo! Spelling Suggestion web service. This mainly fixes spellingerrors, but also includes commonly-used vendor or family names and otherphrases. If the process does yield one or more results in step 920, instep 922 the top three results are chosen to return to the user.

The top result from position search 904 is used to determine whetherquery recommendation is kicked off. From the top result's match masks,it is determined in step 906 which query term matches the vendor or thefamily, which term matches a product model number, and which term, ifany, does not match any document.

The top result's unmatch mask may identify the unmatched terms. Countingthese occurrences and if the count is 1, it can be determined in step908 that a single term does not match any document. This term to bereplaced is added in step 912.

If the top result's unmatch mask is 0 in step 910, all terms havematched some document. Matched terms are then placed into two groups instep 914: (1) product terms—terms that match vendor, family, and/ormodels, and (2) content terms—terms that match the content of the PDFdocument. This may be done by looking at vendor, family, full, partial,alpha match masks of the top result. If a term is not matched accordingto any of these masks, it is a content term. Content terms to bereplaced are added.

Neighboring terms (or biwords) in a query often offer strongercontextual semantics. The terms to replace may be decided as follows:

-   -   1. ignore terms that are vendor or family    -   2. if the term has number, include it    -   3. form a biword using the term and the one before it, if any    -   4. form another biword using the term the one after it, if any    -   5. include the bywords

A dictionary provides a collection of words from which candidates areselected for recommendations. The dictionary may be formed in optionalstep 916 based on the following constraints, whichever is known:

1. vendor name2. family name3. matched product model numbersThese are determined using the top result's match masks.

For example, for query “canon a45” it is found that “a45” is theunmatched term and “canon” is the vendor. The database's model table isthen asked to give up all the model number parts for canon. This couldbe a big collection. The valid model number “a40” should match “a45”most closely and be returned as one of the alternatives.

For query “canon powershot a45”, the database is asked to confine themodel parts to those models that match both vendor canon and familypowershot, which should produce a smaller dictionary.

In an alternate embodiment, the dictionary may be pre-defined orpre-constructed.

For each term to replace, in step 918 an alternative is determined fromthe dictionary based on a proximity algorithm. The algorithm assumes asinput a list of dictionary terms (known model names that may consist offull model name, alphanumeric or alpha only model parts, etc.), and thequery term that needs a recommendation. The output is a sorted list ofrecommended terms, the models each recommendation represents, and ascore (lower the better) for each recommendation. The steps of thealgorithm are as follows:

-   1. Create the feature vectors for the dictionary terms. Each    dictionary term is converted into two feature vectors: (i) histogram    of alphanumeric character count (counts number of a, b, z, 0, 1, . .    . , 9); and (ii) bi-character and tri-character histogram    represented as hashmap (referred to as multi-character histogram).    In order to save space (36*36*36 to at most 2*N−3, where N is the    term length), each bucket of the histogram is converted into a    integer value and its count is stored in the hashmap.-   2. Construct the feature vectors for the query term. Details of    feature vector same as above.-   3. Filter out dictionary terms whose length is over a threshold    greater than or less than the length of the query term.-   4. Compute the distance between dictionary term and the query term.    The distance consists of a distance score weighting the following:-   1. Difference in length of dictionary and query term-   2. Number of different characters in the alphanumeric histogram-   3. If a. and b. are below a threshold then compute a distance score    based on multi-character histogram.-   4. Normalize the distances based on the query term length.-   5. Sort all the distances and cut-off at some a priori defined    threshold distance.

The parameters and thresholds in the above mentioned methods can beadjusted to consider the following:

-   1. Allow at most n character mismatches (e.g., n=3)-   2. Weight mismatch at beginning of the term more than the mismatch    at the end of the term—thus for the query term, d100, term d101 is    recommended with a lower distance score (lower score the better)    than the term e100.    The query string as the user enters is parsed for performing the    search. The main transformations are:    -   stop words such as “a” are removed    -   words separated by punctuations are broken up. E.g., “dcr-hc20”        becomes “dcr hc20” neighboring words are concatenated to form        biwords and are appended        After suggestions are produced, the right term(s) may be        replaced in the original query and other terms kept untouched.        This may be achieved as follows:    -   get a list of query term tokens. These tokens are saved during        query string parsing. They include stop words and words split up        by punctuation. E.g., for “the sony dcr-hc22 picture red-eye”,        the tokens are {the sony dcr hc22 picture red eye}    -   find the char position range of the replacement. Suppose        dcr-hc22 is to be replaced, and the char position range in the        original query is 9 to 16.    -   loop through each token obtained in step 1    -   for each one, get its position in the parsed query. Because stop        words are removed, a token may not appear in the parsed query or        its position is changed in the parsed query. E.g., the positions        for the example are shown in Table 16.    -   add the token to the output if the following are all true:        -   the token's term position in the parsed query is −1 or it is            not at the position to be replaced        -   the token is not part of the suggestion        -   the token is outside the char position range found in step 2        -   the token has not been previously added otherwise add the            suggestion to the output if the following are all true:        -   the token's term position in the parsed query is the            position to be replaced        -   the token is within the char position range found in step 2        -   the replacement has not been previously added

TABLE 16 the sony dcr hc22 picture red eye char pos in original query 04 9 13 18 26 30 term pos in original query 0 1 2 3 4 5 6 term pos inparsed query −1 0 1 2 3 4 5 to be replaced? no no yes yes no no no

-   -   This algorithm prevents the following malformed query        suggestions from happening: missing stop words        -   duplicate replacement like: “the sony dcr-hc20 dcr-hc20            picture . . . ”        -   duplicate punctuation-separated terms like: “ . . . picture            red-eye red-eye”    -   In addition, the following verification steps may be performed        after getting the query suggestion.        -   if the input term is biword, the recommendation must also be            biword        -   the left and right parts of the recommended biword is            similar to those of the input biword. I.e., if they have            numbers before, they must have numbers after.        -   the recommended term must not be the same or a substring of            the input term. If so the recommendation does not seem to be            an enhancement.

Query Processing

Referring again to FIG. 2, in one embodiment, the content of thedocument is stored inside the index 224. Each word from the content isfurther tagged with the section and paragraph from which the word comesfrom. After a query is submitted to the search engine, the query isprocessed to retrieve the matching documents from the search index 224.

Matching Content

FIG. 10 illustrates an example of a traditional lookup 1002, merge 1004,and sort 1006 which may be implemented in some embodiments. A searchengine may perform a look up 1002 for the term given in the query in theindex, and then return a list of document ids in ascending order forthat term. Then a merge process 1004 is used to combine the termsmatched for each document together to form a score based on how manyterms matched for each document as well as other information such as theterm frequency in that document and the overall term frequency acrossall documents.

An example of a preferred embodiment for content lookup, merge, and sortis shown in FIG. 11. In this embodiment, a unique lookup 1102, merge1104, and sort process 1106 that take into consideration the section andparagraph information may be used. In the lookup 1102, each term islooked up against the search index to find the list of documents thatcontains the term. However, in addition to the document id, the lookupprocess returns the “section id, paragraph number” for each term aswell. Since the indexing process encodes the section id and paragraphnumber into a 32-bit position id value, a list of <document id, positionid> integer pairs is returned in ascending order.

For the merge process 1104, all terms appearing in the same paragraphare combined to form a local paragraph score, and then all paragraphsfrom the same section are combined to form a section score. Finally, thesection scores from the same document are used to produce a documentscore.

The search result is still sorted using sort process 1106 by the finaldocument score as before. But for each document, not only is the scorefor that document produced, but also the list of sections and for eachsection, a section score and the top 3 paragraphs (or more or less) thathave the best match for that section are stored. Additionally, a set offlags indicating which term has matched for this document in the resultis returned. These flags can be used by the application to furtherrefine ranking, create query recommendation, and control display.

Content Scoring

For example, in one embodiment, a score is generated for each matchingdocument during the merge process. This score may be built up piece bypiece using the following illustrative process or variations thereof.

For each paragraph, determine how many keywords matched for thatparagraph and which keywords matched for that paragraph.

For each section, find up to 3 top paragraphs. This is done by firstfinding the paragraph with the highest number of matching keywords. Thenlook for 2 other paragraphs that compliment the first found paragraph. Acomplimentary paragraph contains the most number of keywords not alreadycovered by the found paragraph. When multiple paragraphs have the samelevel of complimentary value, then the paragraphs closest to the foundparagraph are chosen.

Create a section score by counting the total number of differentkeywords matched from all paragraphs of that section, and then adjust itusing the scores from the top 3 paragraphs. Also adjust the score bytaking into account any matches from paragraph 0. Paragraph 0 indicatesthat the title of the section matched. Also, the score can be adjustedby counting how many bi-words matched inside this section as well.

For each document, create a document score by looking at the totalnumber of keywords matched, and then adjust the score using the bestsection score from this document.

The result of the document scoring is a set of object containing thefollowing information for each document score:

A document id

A document overall score

A list of section scores. For each section score:

section id

section overall score

A list of up to 3 paragraphs. For each paragraph:

a paragraph id

a paragraph score

A list of flags, indicating which term has matched in this document

Matching Context and Context Scoring

In one embodiment, context matching is done at the same time as contentmatching because the context information is stored inside the sameindex, with the term position set to section 0. There is no additionallogic required to figure out if a term matched inside the context.Further, context scoring is done by first determining if a match is forthe context. This is easily implemented by checking the section numberof the match for a document. If a match results in section 0, then it isfor the context. Then, based on the matching paragraph id, it can bedetermined which one of the meta data the term matched in. For example,if the term “sony” produces a match on section 0 and paragraph 0, thenit is known that “sony” is a vendor term for this document. However, ifthe term “sony” produces a match on section 12, paragraph 3, then thedocument is not about sony, but the word sony is mentioned inside thecontent of the document

Further, during context scoring, score values for the following metadata fields are produced:

Vendor

Family

Full model

Partial model

Document type

Document title

Then the values for these meta fields are added to the score valueproduced from the content matches to create the final document score.Additionally, taxonomy matching may be performed as part of or separatefrom context scoring utilizing taxonomy information 232.

When a term matches in both the vendor/model/family context and thecontent, its importance may be reduced for the content section scoring.For example, if a document is about a “sony” product, then “sony” maymatch inside the vendor context meta data field. However, sectionreferences to the term “sony” inside the content carry less meaning thanother terms such as “focus”.

The value given to a term matches in the meta field is generally greaterthan the same match found in the content field. For example, if the term“manual” matched the “Document Type” field, then this document may get ahigher score than another document that has this term matched only inits content.

The meta fields contain special words that have strong semantics for adocument. By leveraging these special terms inside the meta field, notonly is a better and semantically more relevant ranking created acrossdocuments, but better ranking is also produced within the sections ofthe same document.

One of the query term is the word “_len”. “_len” is a special term thatcan only match inside the context meta data. There is only one len termfor a document. This term exists in section 0, paragraph 10 or above.During the context scoring, the paragraph id of the match for “_len” istaken and subtracted by 10. The resulting number is the encoding fullmodel number length. The full model length is used to assist incomputing the score value for the full and partial model match.

It is also noted which term matched which meta field. This informationis stored inside a set of flags and passed to the application layer. Theapplication layer uses this information to perform query recommendationand adjust display ranking.

Query Performance

Because searches may be performed into sections and paragraphs of adocument, such a search takes more computational cycles when compared toa traditional document level searcher. Assuming that a traditionalsearch engine uses O(N) to locate relevant documents, where N is thetotal number of documents. The current approach would consume O(N*S*P)where S is the average number of sections per document that has at leastone term match and P is the average number of paragraphs per sectionthat has at least one term match. It is estimated that a document has anaverage of 100 logical sections with each section containing 30paragraphs. When a document matched the given query, roughly 25% of thesections may contain at least one match, and within each matchingsection, 50% of the paragraphs may contain a match. As a result, thecurrent document search would perform O(375*N) comparing to atraditional search engine. But a worst case performance happens when aterm matches in all paragraphs. In that worst case, the performance isO(3000*N), which is acceptable.

Understanding the performance characteristics allows for thedetermination of when to start distributing the search loads acrossmultiple servers.

Post-Processing Search Results

Referring again to FIG. 2, in one embodiment, results of a search 234may be post processed to improve the results. A multi-stage postprocessing may be employed to efficiently and effectively filter outpoor results or boost more relevant results. A poor result is defined asa result without a good product match resulting from either a lowproduct score or an unintended product match for a very genericalphabetic query. The PDF search results are post processed by filteringout results with poor product matches, and re-ranking results based ondocument type.

After a user query 226 is submitted to a search engine 236, the result234 is a list of documents ordered by the search result score. Thesearch result score is a combination of the content score and contextscore. Content score is the score given to the document based on keywordmatches inside the sections and paragraphs of the document content.Context score is based on the keyword matches inside the meta data aboutthe document. Meta data includes items such as vendor, model, family,title, and document type, and may include taxonomy-related information.

For each document returned in the result list, the following informationis returned:

Mask of query terms that matched in content or context

Mask of query terms that matched in vendor

Mask of query terms that matched in model

Mask of query terms that matched in family

Mask of query terms that matched in vendor

Mask of query terms that matched in title

Mask of query terms that matched in document type

A combined document score

A product only score

A list of sections that contain at least one term that matched

For each section above:

A section score

Paragraph id from up to 3 paragraphs from that section that are pickedfor summary

In one embodiment, results with poor product matches are filtered out.For example, one of the assumptions concerning the PDF search results isthat a PDF document should not be returned unless the product model isrelevant to the user query. Irrelevance of the PDF document can occureither due to a mismatch (e.g., all query terms match well in thecontent, but don't match a particular product) or due to a generic,non-product-specific user query (certain words in the query match aproduct, but these are not specific enough).

The former case (product mismatch) may be handled via a threshold on thedifference between consecutive document scores. If the product scoredifference falls below a threshold then all documents below the currentdoc are filtered out.

In order to handle generic query terms that may not be product specific,such as numbers that may represent features (4800 dpi, 50 inch, etc.) orgeneric terms in a product (product such as “digital camera solutiondisk”) further checks may be employed. For instance, if there isn't avendor or family match then there is an alphanumeric product model matchfor the product model to be considered relevant to the query. Thus,“dvd101 picture quality” may return a PDF document for sony dcr-dvd101,whereas “101 picture quality” or “dvd picture quality” may not.Additionally, if a vendor or family have matched then either there is anumeric product term match (thus, “Kodak 4800 picture quality” mayreturn a PDF document, but “Kodak dc picture quality” may not), or incase of alphabetic product term matches, there is a complete productmatch. Thus, “canon digital camera solution disk” may return a PDFdocument for the product “digital camera solution disk”, whereas “canondigital camera” may not return a product document.

In yet another embodiment, results may be re-ranked based on doctype.For example, certain doctypes (document categories) are considered ahigher interest than others for generic user queries. In order to boostthe rank of documents of these categories, a specific weight is added tothe document types. This boost is referred to as the docTypeBoost.

All things being equal, this boost ranks certain types of documents overothers. Specifically, user manuals are given the highest weight.Therefore, a query with only the vendor and product match maypreferentially show a user manual before a warranty document.Additionally, a higher weight may be assigned to a textual documentmatching a term in the index of a document and present on a page of thedocument pointed to in the index in association with the term.

Section Summary Reconstruction

In another embodiment, section summary reconstruction may be performed.For example, when a document is returned as a match, the section summaryis displayed from that document. Sometimes, the user query is aboutselecting the document as a whole, rather than searching for itemswithin the document. For example, if the user query is “Sony dvd101 userguide”, then the user is probably searching for the entire document. Ifthe user query is “Sony dvd101 focus settings”, then the user isprobably searching for the section in the document about focus settings.

While the search engine may return sections within a matched document,these sections may not be relevant for display if the user query isabout the entire document. Rather, each document is preferably postprocessed in the result set with the following logic to detect thissituation. First, the match masks are used to see if all terms of thequery appear in vendor, family, model, title, and document type. If theydo, the document's matching section is changed to include section 1,which is the first chapter, and optionally a section with the titleincluding the keyword “Specification.”

With this processing, query results for searches for product documentsdisplays the title page of the document as the first section and thespecification section (if found) as the second section. The originalmatched sections from the search engine are ignored.

FIG. 12 is a flow diagram of a method 1200 for processing a search queryin accordance with one embodiment of the present invention. As anoption, the process 1200 may be implemented in the context of thearchitecture and environment of FIGS. 1-11. Of course, however, theprocess 1200 may be carried out in any desired environment.

As shown in FIG. 12, a search query containing terms is received in step1202. In step 1204, at least some of the terms are looked up in a searchindex for identifying sections of documents containing the at least someof the terms. Additionally, in step 1206, a content score is generatedfor each of the sections based at least in part on a number of keywordsfound in the sections of each document. It may also be determinedwhether the search query includes a product identifier or portionthereof associated with a product, and if so, the documents not relatingto the product associated with the product identifier may be filteredout. Further, in step 1208 an indicator of at least one of the sections,or portion thereof, is selected and output based at least in part on thecontent score. An indicator of a paragraph of at least one of thesections may also be selected and output, where the selecting andoutputting of the indicator of the at least one of the sections, orportion thereof, may be based at least in part on types of thedocuments. It may also be determined whether the search query isdirected to an entire document rather than one or more sections thereof,and if so, an indicator of the document may be selected and outputinstead of the at least one of the sections, or portion thereof, of thedocument.

Additionally, a search may be performed for at least some of the termsin the search index in order to attempt to match one or more of theterms to context information in the search index, where the contextinformation is associated with at least one of the documents. A contextscore may also be generated based at least in part on the matching ofthe terms of the context information, where the selection of the atleast one of the sections, or portion thereof, is also based at least inpart on the context score.

In another embodiment, an index structure for keyword searches ispresented, the index structure being embodied on a computer readablemedium, e.g. a hard disk, a magnetic tape, ROM, RAM, optical media, etc.The index structure comprises a plurality of content words.Additionally, the index structure comprises, for each of the contentwords, at least one document identifier, e.g. an id, containinginformation about a document containing the content word. For each ofthe document identifiers, the index structure further comprises at leastone position identifier containing information about a section in thedocument containing the content word.

Additionally, at least some of the position identifiers may furthercontain information about a paragraph in the section of the documentcontaining the content word. Further, at least some of the positionidentifiers may include a weighting value of the content word. Furtherstill, the weighting value may be based at least in part on a positionof the content word in the document. The index structure may furthercomprise context meta data associated with at least some of thedocuments, where the context meta data indicates a context of thedocuments associated therewith. Additionally, at least some of thecontext meta data may be weighted.

Product Search User Interface

In yet another embodiment, a search WEB portal may provide an interfacefor users to enter product queries in a Web browser. After the query isentered, the search results are displayed. Users can navigate the resultpages using various hyperlinks to see more results, preview site, aswell as submit additional queries.

The portal provides unique features such as quick preview, dynamicnavigation, and persistent states. Further, the portal provides simplequery input control, like other search engines, displays the title, url,and summary of search results, and displays search results in channels.Also, the portal provides channel drill down to see more results,enables users to quickly preview selected search results, providesreasonable “fast” response time, and allows customization of thedisplay. The portal may support any web browser, for example, InternetExplorer 6+ and Firefox 1.5+ on WINDOWS® 2000/XP and Safari 1.2+ on MacOS X 10.2+.

Landing Page

FIG. 13 is a landing page 1300 in accordance with one embodiment of thepresent invention. As an option, the landing page 1300 may beimplemented in the context of the architecture and environment of FIGS.1-12. Of course, however, the process 1300 may be carried out in anydesired environment.

As shown in FIG. 13, the logo 1302 displays the company logo.Additionally, the tagline 1304 displays the company tagline. The taglinecan change dynamically by editing a template file without restarting theserver. Further, the user input element 1306 is an entry box used by theuser to enter the query for the search. The examples element 1308 is anarea which contains example queries to educate the user on how to usethe system. Like the tagline, this area is dynamic and can changewithout restarting the server. Further still, the other informationelement 1310 is an informational area used to communicate with the user.This area can also be dynamically updated without restarting the server.Also, the footer element 1312 contains a list of hyperlinks to pagessuch as about us, terms of use, privacy policy, and feedback.

A possible landing page implementation 1400 is shown in FIG. 14, thevarious portions of which are self explanatory.

Search Result Page

FIG. 15 is a search result page 1500 in accordance with one embodimentof the present invention. As an option, the search result page 1500 maybe implemented in the context of the architecture and environment ofFIGS. 1-14. Of course, however, the search result page 1500 may becarried out in any desired environment.

As shown in FIG. 15, the logo element 1502 is a smaller version of thecompany logo. Clicking on the logo brings the user back to the landingpage. The user input element 1504 allows the user to enter another queryto search without going to the landing page. Additionally, the queryrecommendation element 1506 displays the query recommendation after asearch. If there is no query recommendation, then this area is leftblank. The other controls element 1508 displays control buttons, forexample, “invite friends,” “submit feedback,” etc.

Below the header portion, the main area of the display is divided into aleft hand side (LHS) and a right hand side (RHS). The two sides areresizable with a splitter in the middle. Additional controls are alsoavailable to close the RHS or expand the RHS.

Furthermore, inside the LHS, the channel listing element 1510 displaysthe channels under which the data is displayed. For example, channelsmay be labeled “Top Results,” “Product Documents,” “Forums & Blogs,”“Reviews & Articles,” “Manufacturer Info,” “Stores,” and “Other.” Also,the search results element 1512 is the main display of search results.Each result is made of a title, a summary, and a URL link to the fulldata. Pressing in the body of the summary brings up a preview of thefull data in the RHS. A search result may be for a Web page or for asection of a PDF document. The search results changes based on theselected channel in the channel listing element 1510. Further, thefooter element 1514 contains hyperlinks to web pages, for example,“about us,” “terms of use,” “privacy statement,” and “feedback.”

Inside the RHS, the RHS preview element 1516 displays the selectedsearch result from the search results area. The displayed page can beeither a PDF document page or the content from a Web site. As the userselect different search results from the LHS search results area, thecontent of the RHS changes accordingly. The preview area is a great wayto quickly review the search results without losing the left hand sideresults. As wide aspect ration monitor becomes more common, there isenough horizontal space on the screen to show both the search result andthe preview. For users who like a traditional way of viewing the searchresults without the preview, they can close the preview area entirely.

An example of an implementation of the search results page 1500displaying a PDF document page 1602 is shown in FIG. 16. Another exampleof an implementation of the search results page 1500 displaying contentfrom a web site is shown in FIG. 17.

Interface Implementation

In one embodiment, the user interface may be implemented using Java JSP,Tomcat Servlet Container, HTML, JavaScript, CSS, and AJAX. The JSP maybe used to place server side dynamic content into the various web pages.HTML and CSS may be used to perform the visual layout. JavaScript andAJAX may be used to provide dynamic changes in response to user actionson the web page.

One preferred embodiment of the process of submitting a query anddisplay results between the client browser and the server is shown inFIG. 18. As shown in FIG. 18, in step 1802 a user enters a query, and aPDF search and query recommendation are performed in step 1804. The PDFresults are rendered in step 1806, and in step 1808 a request is sent toAJAX for web results. Additionally, a web search is performed in step1810. Further, the web results are rendered in step 1812.

Additionally, in step 1814 a request is sent to AJAX for a preview.Preview content is constructed in step 1816, and in step 1818 it isdetermined if the preview is a PDF page preview. If it is, in step 1820a request is sent for the PDF page, and in step 1822 the PDF page issent and is rendered in preview RHS in step 1828. If the preview is nota PDF page preview, in step 1824 a request is sent to a web site, and instep 1826 the web page is sent and is rendered in Preview RHS in step1828.

Displaying PDF Page Preview

In another embodiment, the PDF page preview may be a single PDF pagedownloaded from our server for display inside the RHS preview pane.Since this page is not HTML, the browser may use a PDF plugin to displaythe PDF page. Browsers that do not have a PDF plugin may not be able topreview the PDF page. One potential way of resolving that issue may beto generate a graphical image of the page on the server and only servethe resulting image file to the browser. Since most browser supportsimage display, the latter approach may provide broad compatibility.

Displaying Web Site Preview

In yet another embodiment, the Web site preview is rendered entirely bythe web browser. The browser submits a HTTP request directly to the website referenced in a search result. The web site is then displayedinside the RHS area in an internal frame. On the IE browser, theinternal frame is further adjusted such that a zoom factor is applied.As the user move the slider to expand and shrink the RHS window, therendered web site content zooms in and out accordingly.

Displaying web site inside an internal frame has an effect in that someweb site uses JavaScript to detect if it is being rendered inside aninternal frame. If it is, it would redirect the browser go the site anddisplay the site content inside the root window. The user interface codedoes its best to detect this behavior. Once detected, the client sideJavaScript notifies the potential problem site with the server. Later,it is verified that the site does have this behavior. If it does, thesite is added to a blacklist.

For web results that are on the blacklist, user clicking on the resultdoes not show the preview in the RHS window. Instead, a new top windowis created to load the web result.

This situation may be addressed by deploying a Web browser plugin. Theplugin may render the given web site in the RHS internal frame. Becausethe rendering is done by the plugin, the web site is shown in a “top”level window. A plugin for the WINDOWS® platform can be easily createdby using ActiveX and loading a WebBrowser control that is built into theoperating system. Using the WebBrowser control can also provide zoomin/out capabilities. For other platforms, it may be determined how theplugin can be easily implemented.

In another embodiment, a combination approach may be taken. For userswho do not want to install a preview plugin, the existing method may beused with certain sites blacklisted. For users with the plugin, webpreview of all sites may be provided. Having the plugin may also allowthe implementation of keyword highlighting inside the web page for theuser.

User Interface States

In yet another embodiment, the user interface may track the previewresult location, the show/hide of the RHS preview window 1516, and theleft to right split ratio. Preview result location is maintained as theuser navigate away from the search result page and then use thebrowser's back button to come back. When the user is back to the searchresult page, the page automatically select the last previewed result.The show/hide and left-to-right split ratio are remembered persistentlyfor the user's browser.

Server side persistence may also be implemented for user interfacestates. Having server site persistence allows the user interfacepreferences to be transferred across different browsers. Server basedpersistence would require the user to sign up an account.

In addition, AJAX may be used in the user interface to dynamically loaddata into various frames. Using AJAX gives the user a feeling of fasterresponse time. For example, the results for the PDF portion of thesearch are displayed first and quickly, and then the Web search resultsare displayed.

However, web browsers may not support AJAX. Examples of such browsersinclude Cellphone/PDA, older versions of desktop browsers, and searchengine crawlers. In these situations, a combination of techniques may beused. For browsers supporting AJAX, asynchronous data loading may stillbe used. For other browsers, a traditional technique of constructing theentire search result content, which includes PDF results and Webresults, on the server, and then sending that data to the browser, maybe used.

Splitting Product Identifiers

FIG. 19 is a flow diagram of a method 1900 for indexing a productidentifier and logical parts thereof in accordance with one embodimentof the present invention. As an option, the method 1900 may beimplemented in the context of the architecture and environment of FIGS.1-18. Of course, however, the method 1900 may be carried out in anydesired environment.

As shown in FIG. 19, a product identifier is received in step 1902.Additionally, the product identifier is split into logical parts in step1904. If the product identifier is an alphanumeric character string, thelogical parts may include an alphabetic part and a numeric part of thealphanumeric character string. Further, in step 1906 the productidentifier and the individual logical parts in association with aparticular document or portion thereof are indexed in an index, and theindex is stored in step 1908. Also, if the product identifier comprisesmultiple logical parts separated by a space, punctuation mark, etc., atleast some of the logical parts may be indexed as a single consecutivecharacter string.

Additionally, the product identifier may be indexed in a field for fullterms, whereas the logical parts may be indexed in a field for partialterms. If the logical parts include an alphabetic part and a numericpart of the alphanumeric character string, the alphabetic part and thenumeric part may be each indexed in a field for partial strings, and/orthe alphabetic part may be indexed in a field for alphabetic strings.

In one embodiment, a model number is split into parts and stored 3areas: full, partial, and alpha-only. One example of splitting logic isas follows:

Loop 1:

-   -   7. replace all consecutive punctuations by a single <space>    -   8. split by <space> into individual parts    -   9. create biwords from parts, add these biwords full model, if        not seen before, save item type as full    -   10. create biwords without the period, add these to full model,        if not seen before, save item type as full

Loop 2:

-   -   11. split by <space> from the original model name into words    -   12. remove all punctuation for each word, add to full model, if        not seen before, save item type as full    -   13. for each word, replace all consecutive punctuations by a        single <space> for each word    -   14. then split by <space> into parts    -   15. if a part is NOT alpha only, add to partial if (not already        added before) OR (added before as a full AND part length is        <minLen), save item type as not full    -   16. for each part, further split by CamelCase to produce a list        of alpha-only and digit-only tokens    -   17. if a token is digit only, add to partial if (not already        added before) OR (added before as a full AND part length is        <minLen), save item type as not full    -   18. if a token is alpha only, add to alpha if (not already added        before) OR (added before as a full AND part length is <minLen),        save item type as not full    -   19. Also add        <alpha><numeric><alpha>.<numeric><numeric><alpha><numeric>.<alpha>        to partial if (not already added before) OR (added before as a        full AND part length is <minLen), save item type as not full

Another example of splitting logic, where parameter minLen no longerplays a role, is as follows:

Loop 1:

-   -   1. replace all consecutive punctuations by a single <space>    -   2. split by <space> into individual parts    -   3. create biwords from parts with a period, add these biwords        full model, if not already in full    -   4. create biwords without the period, add these to full model,        if not already in full, if the biword has a digit, also add to        partial, if not seen in partial before

Loop 2:

-   -   5. split by <space> from the original model name into words    -   6. if there is only one word, remove all punctuation and add        this word to full if not already in full; if it has a digit, add        to partial if not already in partial    -   7. for each word, further split by punctuation AND CamelCase to        produce a list of alpha-only and digit-only tokens    -   8. if a token is digit only, add to partial if not already in        partial    -   9. if a token is alpha only, add to alpha if not already in        alpha and it is not the whole model    -   10. Also add        <alpha><numeric><alpha>.<numeric><numeric><alpha><numeric>.<alpha>        to partial if not already in partial

The logic illustrated above results in that if a model is a single word,this word goes into the full and not in the partial or alpha area.Additionally, all biwords, with or without periods, go into the fullarea. All words and biwords from full without a period that alsocontains a digit, go into the partial area. Further, all non-biwordsthat don't contain a digit go into the alpha area, except for the wordthat is the entire model. An example of this technique is illustrated inTable 17.

TABLE 17 Model Full Partial Alpha DCR-HC96 DCR.HC96 DCRHC96 DCR HCDCRHC96 HC96 96 HC.96

When a search query is received with part of the identifier or anincorrect identifier, the system may make the best match between thesearch term and a variant in the index. Additionally, or alternately,the system may recommend a likely match.

FIG. 20 is a flow diagram of a process 2000 for indexing a productidentifier and variations thereof in accordance with one embodiment ofthe present invention. As an option, the process 2000 may be implementedin the context of the architecture and environment of FIGS. 1-19. Ofcourse, however, the method 2000 may be carried out in any desiredenvironment.

As shown in FIG. 20, a product identifier is received in step 2002.Additionally, the product identifier is split into logical parts in step2004. Further, in step 2006 the product identifier and alternatecombinations of the logical parts in association with a particulardocument or portion thereof are indexed in an index, and the index isstored in step 2008. Also, the product identifier may be indexed in afield for full terms, whereas the alternate combinations may be indexedin a field for partial terms.

In another embodiment, a method for processing a search query ispresented. In use, a search query containing one or more terms isreceived. Further, a search index containing complete productidentifiers and variations thereof is searched for attempting to matchthe one or more terms to the product identifiers or the variationsthereof. The variations may include a partial product identifier, areordered product identifier, a modified product identifier, etc.Additionally, if one or more of the terms matches a complete productidentifier or variation thereof, an indicator of the document or aportion thereof associated with the matching product identifier isselected and output. If one or more of the terms does not match acomplete product identifier or variation thereof, an attempt may be madeto make a best match between the one or more of the terms and theproduct identifiers and variations thereof, and possible matches may beoutput for user selection. The variations of the product identifiers mayinclude at least one of: parts of the product identifiers, continuouscharacter strings, reordered logical parts of the product identifiers,alphabetical characters only, and numerical characters only.

While embodiments of the present invention have been illustrated anddescribed with reference to specific embodiments, various permutationsand modifications will be apparent to those skilled in the art. Forexample, “code”, as used herein, or “module”, as used herein, may be anyplurality of binary values or any executable, interpreted or compiledcode which can be used by a computer or execution device to perform atask. This code or module can be written in any one of several knowncomputer languages. A “module,” as used herein, can also mean any devicewhich stores, processes, routes, manipulates, or performs like operationon data. An “incoming communication device” and “outgoing communicationdevice” may be any communication devices which can be used for takingfax information and inputting the fax information into a module. A “textfile” or “textual format”, as used herein, may be any data format forefficiently storing alphanumerical data. In general, a text file or textformat is any data structure which identifies individual alphanumericcharacters letters, or language characters from any faxed transmission.A “string”, as used herein, is one or more alpha numeric or textualcharacters which are identified as being part of a group (such as ahuman name). It is to be understood, therefore, that the variousembodiments of this invention are not limited to the particular formsillustrated and that it is intended in the appended claims to cover allpossible modifications of the teachings herein.

The present description is presented to enable any person skilled in theart to make and use the invention and is provided in the context ofparticular applications of the invention and their requirements. Variousmodifications to the disclosed embodiments will be readily apparent tothose skilled in the art and the general principles defined herein maybe applied to other embodiments and applications without departing fromthe spirit and scope of the present invention. Thus, the presentinvention is not intended to be limited to the embodiments shown, but isto be accorded the widest scope consistent with the principles andfeatures disclosed herein.

In particular, various embodiments discussed herein are implementedusing the Internet as a means of communicating among a plurality ofcomputer systems. One skilled in the art will recognize that the presentinvention is not limited to the use of the Internet as a communicationmedium and that alternative methods of the invention may accommodate theuse of a private intranet, a LAN, a WAN, a PSTN or other means ofcommunication. In addition, various combinations of wired, wireless(e.g., radio frequency) and optical communication links may be utilized.

The program environment in which a present embodiment of the inventionmay be executed illustratively incorporates one or more general-purposecomputers or special-purpose devices such facsimile machines andhand-held computers. Details of such devices (e.g., processor, memory,data storage, input and output devices) are well known and are omittedfor the sake of clarity.

It should also be understood that the techniques presented herein mightbe implemented using a variety of technologies. For example, the methodsdescribed herein may be implemented in software running on a computersystem, or implemented in hardware utilizing either a combination ofmicroprocessors or other specially designed application specificintegrated circuits, programmable logic devices, or various combinationsthereof. In particular, methods described herein may be implemented by aseries of computer-executable instructions residing on a storage mediumsuch as a carrier wave, disk drive, or computer-readable medium.Exemplary forms of carrier waves may be electrical, electromagnetic oroptical signals conveying digital data streams along a local network ora publicly accessible network such as the Internet. In addition,although specific embodiments of the invention may employobject-oriented software programming concepts, the invention is not solimited and is easily adapted to employ other forms of directing theoperation of a computer.

Various embodiments can also be provided in the form of a computerprogram product comprising a computer readable medium having computercode thereon. A computer readable medium can include any medium capableof storing computer code thereon for use by a computer, includingoptical media such as read only and writeable CD and DVD, magneticmemory, semiconductor memory (e.g., FLASH memory and other portablememory cards, etc.), etc. Further, such software can be downloadable orotherwise transferable from one computing device to another via network,wireless link, nonvolatile memory device, etc.

FIG. 21 illustrates a network architecture 2100, in accordance with oneembodiment. As shown, a plurality of remote networks 2102 are providedincluding a first remote network 2104 and a second remote network 2106.A gateway 2107 may be coupled between the remote networks 2102 and aproximate network 2108. In the context of the present networkarchitecture 2100, the networks 2104, 2106 may each take any formincluding, but not limited to a LAN, a WAN such as the Internet, PSTN,internal telephone network, etc.

In use, the gateway 2107 serves as an entrance point from the remotenetworks 2102 to the proximate network 2108. As such, the gateway 2107may function as a router, which is capable of directing a given packetof data that arrives at the gateway 2107, and a switch, which furnishesthe actual path in and out of the gateway 2107 for a given packet.

Further included is at least one data server 2114 coupled to theproximate network 708, and which is accessible from the remote networks2102 via the gateway 2107. It should be noted that the data server(s)2114 may include any type of computing device/groupware. Coupled to eachdata server 2114 is a plurality of user devices 2116. Such user devices2116 may include a desktop computer, lap-top computer, hand-heldcomputer, printer or any other type of logic. It should be noted that auser device 2117 may also be directly coupled to any of the networks, inone embodiment. A facsimile machine 2120 or series of facsimile machines720 may be coupled to one or more of the networks 2104, 2106, 2108.

It should be noted that databases and/or additional components may beutilized with, or integrated into, any type of network element coupledto the networks 2104, 2106, 2108. In the context of the presentdescription, a network element may refer to any component of a network.

FIG. 22 shows a representative hardware environment associated with auser device 2116 of FIG. 21, in accordance with one embodiment. SuchFIG. illustrates a typical hardware configuration of a workstationhaving a central processing unit 2210, such as a microprocessor, and anumber of other units interconnected via a system bus 2212.

The workstation shown in FIG. 22 includes a Random Access Memory (RAM)2214, Read Only Memory (ROM) 2216, an I/O adapter 2218 for connectingperipheral devices such as disk storage units 2220 to the bus 2212, auser interface adapter 2222 for connecting a keyboard 2224, a mouse2226, a speaker 2228, a microphone 2232, and/or other user interfacedevices such as a touch screen and a digital camera (not shown) to thebus 2212, communication adapter 2234 for connecting the workstation to acommunication network 2235 (e.g., a data processing network) and adisplay adapter 2236 for connecting the bus 2212 to a display device2238.

The workstation may have resident thereon an operating system such asthe Microsoft Windows® Operating System (OS), a MAC OS, or UNIXoperating system. It will be appreciated that a preferred embodiment mayalso be implemented on platforms and operating systems other than thosementioned. A preferred embodiment may be written using JAVA, XML, C,and/or C++ language, or other programming languages, along with anobject oriented programming methodology. Object oriented programming(OOP), which has become increasingly used to develop complexapplications, may be used.

While various embodiments have been described above, it should beunderstood that they have been presented by way of example only, and notlimitation. Thus, the breadth and scope of a preferred embodiment shouldnot be limited by any of the above-described exemplary embodiments, butshould be defined only in accordance with the following claims and theirequivalents.

What is claimed is:
 1. A non-transitory computer readable storage mediumhaving an inverted index structure stored thereon for access by aprogram configured to execute keyword searches, the inverted indexstructure comprising: a plurality of content words extracted from anunstructured text document; for each of the content words, at least onedocument identifier containing information about the unstructured textdocument containing the content word; and for each of the documentidentifiers, at least one position identifier containing firstinformation about a section in the unstructured text document containingthe content word and second information about a paragraph in the sectionin the unstructured text document containing the content word, the firstinformation being distinct from the second information.
 2. The invertedindex structure as recited in claim 1, wherein at least some of theposition identifiers further contain information about a page in theunstructured text document containing the content word.
 3. The invertedindex structure as recited in claim 1, wherein at least some of theposition identifiers include a weighting value of the content word. 4.The inverted index structure as recited in claim 3, wherein theweighting value is based at least in part on a position of the contentword in the unstructured text document.
 5. The inverted index structureas recited in claim 1, further comprising context meta data associatedwith the unstructured text document, the context meta data indicating acontext of the unstructured text document associated therewith.
 6. Theinverted index structure as recited in claim 5, wherein at least some ofthe context meta data is weighted.
 7. The inverted index structure asrecited in claim 1, wherein for at least one of the positionidentifiers, the first information is stored within a multi-bit integerof which a first plurality of bits store a section identifier associatedwith the respective section and a second plurality of bits store atleast one priority bit.